METHOD FOR TRANSMITTING SOFTWARE CODE 
FROM A CONTROL UNIT TO A FIELD DEVICE 
OF PROCESS AUTOMATION TECHNOLOGY 



The invention relates to a method for transmitting software code from a control unit to 
a field device of process automation technology, according to the preamble of claim 1 . 

In process automation technology, field devices are often used for registering and/or 
influencing process variables. Examples of such field devices are fill level meters, mass 
flow measuring devices, pressure and temperature measuring devices, etc., which, as 
sensors, register the corresponding process variables fill level, flow rate, pressure and 
temperature. 

Serving for the influencing of process variables are so-called actuators, e.g. valves, 
which alter the flow rate of a liquid in a section of a pipeline, or pumps, which alter fill 
level in a container. 

A large number of such field devices are manufactured and sold by the firm 
Endress+Hauser. 

As a rule, the field devices are connected via a fieldbus (Profibus®, Foundation® 
Fieldbus, etc.) with control systems or control units. These serve for process control, 
process visualization, process monitoring, as well as for configuring and parametering 
of the field devices. 

The field devices perform various functions within the process control. For specific 
standard functions, so-called function blocks with defined communication interfaces are 
available. These function blocks form with corresponding algorithms, which are 
executed in the microprocessors of the individual field devices, special application 
functions. Field devices with microprocessors are referred to as intelligent, or smart, 
field devices. A significant aspect of the function blocks is that they have defined 
interfaces and, therewith, can be linked together by, from relatively simple up to very 
complex, control strategies, which are divided among different field devices. 

In the Foundation Fieldbus Specifications, which are publicly available, various standard 
function blocks are specified. Typical function blocks for field devices are: "Analog 
Input"; "Analog Output"; "Discrete Input"; "Discrete Output"; "PID-Control". Along with 
these basic function blocks, there are also special function blocks: "Analog Alarm"; 
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"Arithmetic"; "Device Control". Recently, also flexible function block are specified by 
Foundation Fieldbus (e.g. Supervisory Data Acquisition); these are freely programmable 
according to the lEC-Standard 61 131. Reference is also made to the lEC-Standard 
51158, in which, besides various fieldbus systems, also the Foundation® Fieldbus- 
technology is specified. 

In order to change function blocks, the corresponding software code must be replaced 
in the memory of the field device. This is most often done by replacing the 
corresponding memory element (EEPROM). Another possibility is to transfer the new 
program part (i.e. the new software code), e.g. from a laptop, using a service-interface 
provided on the field device. To this end, however, manufacturer-specific programs, 
so-called (software-) tools are needed. As a rule, also the transmission protocols are 
proprietary. 

Before a field device can be put in use, it must be configured and parametered. For 
this, among other things, the loading of the control strategy into the corresponding field 
devices is necessary. A known application, which enables this, is the SYSCON system 
of the company, SMAR. With this application, also the correct interconnecting of the 
individual function blocks, as well as the chronological sequencing of the control 
strategy, can be tested. 

Often in process automation technology, field devices of different manufacturers are 
used, for whose complete parametering and configuring manufacturer-specific 
operating programs are required. These are generally also referred to as "tools", i.e. 
operating programs (e.g. CommuWin® of the firm Endress+Hauser), which run on 
computer units, such as e.g. workstations or laptops. In order to enable a universal 
operating of field devices of different manufacturers, an industry standard, FDT (Field 
Device Tool)-Specifications, was created by the PNO (Profibus® Nutzerorganisation). 
Device manufacturers provide their field devices with device-specific software modules, 
DTMs (Device Type Managers), which encapsulate all data and functions of a field 
device. Along with this, graphical operating elements are provided at the same time. 
For execution, the DTMs require, as runtime environment, an FDT frame application 
(FDT container). Such can be a simple operating program (configuring tool) or a control 
system application (engineering tool). The FDT Specifications only specify the 
interfaces, not, however, their implementation. 
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The underlying software-architecture is based on the Microsoft COM/DCOM technology. 
DTMs are implemented as COM components (COM server) and are the software 
interfaces via which the FDT frame application obtains access to the physical field 
device. The graphical operating elements are implemented as Microsoft ActiveX 
controls. Via these graphical interfaces, the user obtains a simple access to the 
physical field device. Besides the field devices, also other devices must be linked into 
the FDT-frame application. These devices, which, e.g. in the form of gateways and 
fieldbus adapters, assume communication tasks, require so-called communication- 
DTMs. A communication-DTM (CommDTM) contains all communication functions and 
dialogs, via which one can influence and activate the parameters of the network, or bus 
connection, as the case may be. These elements are normally likewise implemented 
as ActiveX controls. In the case of the standardized FDT-interface, the CommDTM 
replaces the currently usual manufacturer-specific configuration software of a network, 
or fieldbus interface, as the case may be. The communication channel CommChannel 
corresponds to the driver libraries. 

Currently, for operating and configuring field devices and for changing software code 
in field devices, one needs different, manufacturer-specific programs (tools). Especially 
the changing of software code in field devices is very complex and can, as a rule, only 
be done by a technician on-sit, right at the field device. The programs required for this 
must be, with much effort, produced and tested. If the process automation installation 
of the user contains field devices of different manufacturers, then different operating 
programs and different programs for changing software code are needed. This is 
extremely unsatisfactory for the user. 

An object of the present invention is, therefore, to provide a method for transferring 
software code from a computer unit to a field device of process automation technology, 
wherein the method is distinguished by being simple to perform, at favorable cost. 

This object is achieved by the method steps of claim 1 . 

An essential idea of the invention is to integrate the software code that needs to be 
loaded into the field device first into a software module, which encapsulates various 
data and functions of the field device and which requires, as runtime environment, an 
operating program for field devices. Via the operating program, the software module 
communicates with the field device. The software module represents essentially the 
software driver for the field device, with all device-specific functions and dialogs, as well 
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as the user interface for parametering, configuring, diagnosis and maintenance. 

In a further development of the invention, the software module is a DTM (Device Type 
Manager) and the operating tool is a FDT-frame application, which both meet the FDT- 
Specifications. 

In a further development of the invention, the software code is a function block. This 
function block can be constructed e.g. according to the Foundation® Fieldbus 
Specifications. 

Such a function block contains, among other things, the algorithms, parameters and 
methods for the particular field device. 

Since, during the transmission of a function block into a field device, the function block 
can be significantly tampered with, security mechanisms are needed for preventing a 
virus attack on the field device. In a further development of the invention, a shell 
application is installed in the field device. The shell application enables execution of the 
function block, which is to be transferred into the field device, in the field device. 

The invention will now be explained in greater detail on the basis of an example of an 
embodiment presented in the drawing, the figures of which show as follows: 

Fig. 1 schematic view of a network of process automation technology; and 

Fig. 2 schematic view of an FDT-frame application with connection to a field device. 

Fig. 1 details a network of process automation technology. Connected to a data bus 
D1 are a plurality of control systems, or units, (workstations) WS1 , WS2, which serve 
for process visualization, process monitoring and for engineering. Data bus D1 works 
e.g. according to the HSE (High Speed Ethernet)-Standard of Foundation ® Fieldbus. 
Via a gateway G, which is also referred to as a linking device, data bus D1 is connected 
with a fieldbus segment SM1. Fieldbus segment SM1 includes a plurality of field 
devices F1 , F2, F3, F4, which are connected together via a fieldbus FB. Fieldbus FB 
works according to the Foundation Fieldbus Standard. 
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Fig. 2 is a schematic representation of an FDT-frame application, which runs on one of 
the control units WS1 , WS2. The FDT frame application can be the operating program 
PACTware® (PACTware Consortium e.V.) or FieldCare® (Endress+Hauser), which 
require a Windows® environment. The FDT-frame application is responsible for the 
project database, communications to the bus systems, management of the field device 
catalog, management of the users and access rights, etc.. Via different interfaces S1 , 
S2 (according to FDT-Specifications), an embedding of the software module DTM-1 
occurs. DTM-1 is in the form of a DTM. DTM-1 encapsulates the data and functions 
of the field device F1 and requires, as runtime environment, the FDT-frame application. 
DTM-1 enables access to device parameters (online and offline), device adjustment 
and configuration, diagnosis of device status and a manufacturer-specific device 
adjustment with corresponding look and feel. DTM-1 also provides, in the form of 
independent Windows® applications, graphical elements for the adjusting of the field 
devices. 

According to the FDT-concept, various DTMs of different manufacturers can be 
embedded into the FDT-frame application. 

Via an interface S3, the FDT-frame application communicates with the field device F1 . 
The hardware connection occurs via a bus connection BA, data bus D1 , gateway G1 , 
the fieldbus and the fieldbus interface FS1 . Integrated in the DTM-1 is, additionally, a 
function block FB, which is composed of a function-block user-interface FBUI and the 
function-block software-code FBC of focus here. The software code of the function 
block FB is in the form of a function block according to the Foundation® Fieldbus 
Specifications. This function block includes e.g. algorithms, parameters or methods of 
the field device F1 . Especially the parameters of the function block can be changed via 
the function-block user-interface FBUI. 

The manner in which the invention operates will now be explained in greater detail. 
Parameter values can be transferred in simple and known manner from the control unit, 
e.g. WS1 , to the field devices F1 , F2, F3, F4. First, the communication connection to 
the physical device is established. For this, FDT provides the communication channels 
CommChannels. Following the establishing of the communication connection, the 
software code FBC is transferred from the control unit, e.g. WS1 , to the field device F1 
in appropriate manner, such as in the manner used for conventional parameter values. 
The establishing of the connection and the communication with the physical device is 
already part of the FDT specifications. For executing the software code in the field 
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device F1, a function-block shell with associated interfaces S1\ S2' is provided. The 
function-block shell represents an application program interface between fieldbus stack 
and function-block applications. For preventing the transfer of software code foreign 
to the manufacturer into the field device, provision is made in the function-block shell 
for checking the authenticity of the DTMs. Only in the case of DTMs from DTMs 
certified by the manufacturer is the transfer of software into field devices of the 
manufacturer permitted. In this way, it is prevented that defective or virus-contaminated 
software code can get into the field device. 

A manufacturer-specific program for transferring software code FBC to field devices is 
no longer necessary. A standard operating program is sufficient instead. With an 
operating program, the FDT-frame application, software code can be changed in field 
devices of different manufacturers. These changes can be carried out, without 
problem, by the user. To do this, it is only necessary to load the field device 
manufacturer-provided DTM with the changed software code into the control unit and 
initiate the process via a corresponding screen command "Execute Software Update". 
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